3 of 3: scalability fix: refactor task history persistence to use file-based storage #3785

KJ7LNW · 2025-05-21T09:08:42Z

Note to Reviewer

This is a PR series, so the line numbers shown by Github are exaggerated. The commit series clearly marks where each PR begins using lines that say NOTICE: PR ____ STARTS HERE. See below for the annotated diffstat.

The commits tell a clean story, it will be easier to understand what is happening here by looking at each commit individually under "Commits" than by looking at all of the files that were changed.

The best place to start your review is here:

Dependencies

Change Overview

Previously:

These the issues create a very slow choppy experience:

The global state key taskHistory stored a copy to every single HistoryItem ever created by the user---thousands! This multi-megabyte array you to be loaded in the extension state, so every single extension state update would transfer ~10MB between the user interface and back.
HistoryItem.task contains the first message of every task, so any time someone create a file using @mention or pasted huge amounts of content into the original message was loaded into global state
Even worse than the large volume of data traveling between the extension and user interface was the sequential scan across that entire array to find the matching active taskId (UUID). Every single HistoryItem modification had to perform the following:
1. VS Code: read a single monolithic record from VS Code's SQLite extension database
2. VS Code: deserialize the >10MB JSON array object
3. Roo: fetch the entire >10MB array taskHistory object from global stage
4. Roo: sequential scan (!) for the HistoryItem object that needed to be updated
5. Roo: pass the object to VS Code
6. VS Code: serialize the object into a single JSON string
7. VS Code: write the entire string as a single record to the SQLite extension database (here be dragons, and possibly race conditions)

Upgrades!

The hallmarks of this upgrade are as follows:

Much better performance using:
- YYYY-MM -> Workspace -> HistoryItem -> date indexes (~50kB in size in monthly buckets)
- Workspace -> date indexes (~3kB)
- Only IDs and integers are stored in the indexes, HistoryItem objects can be large so they are stored directly and files in tasks/<uuid>/history_item.json
Atomic read-modify-write JSON transactions:
- these are used for all index updates
- if an update is attempted but not needed, the transaction is cancelled without modifying the index file for better performance
HistoryView and HistoryPreview only fetch the number of items that they need for the backend, and the indexes above are used to directly fetch the relevant HistoryItem objects:
- only the index is needed for the search result are read fzf

Diff Annotation

// core transactional history index implementation
 src/core/task-persistence/taskHistory.ts                    | 954 +++++++++++++++++++++++++
 src/core/task-persistence/taskHistorySearch.ts              | 142 ++++

// primary user interface changes
 webview-ui/src/components/history/HistoryView.tsx           | 573 ++++++++++++---
 webview-ui/src/components/history/useTaskSearch.ts          | 214 ++++--
 src/core/webview/webviewMessageHandler.ts                   | 143 +++-

// generic user-facing upgrade interface 
 webview-ui/src/App.tsx                                      |  16 +
 webview-ui/src/components/upgrade/UpgradeHandler.tsx        | 157 ++++
 src/core/upgrade/upgrade.ts                                 |  36 +

// history item types:
 packages/types/src/global-settings.ts                       |   3 -
 packages/types/src/history.ts                               |  53 ++
 
// minor plumbing changes to remove `taskHistory` datatypes:
 src/extension.ts                                            |  18 +-
 src/core/config/ContextProxy.ts                             |   3 +-
 src/core/webview/ClineProvider.ts                           |  50 +-
 src/shared/ExtensionMessage.ts                              |  10 +-
 src/shared/WebviewMessage.ts                                |   7 +
 src/shared/globalFileNames.ts                               |   1 +
 webview-ui/src/components/chat/ChatTextArea.tsx             |   2 -
 webview-ui/src/components/chat/ChatView.tsx                 |  27 +-
 webview-ui/src/components/chat/hooks/usePromptHistory.ts    |  16 +-
 webview-ui/src/components/common/SpinnerOverlay.tsx         |  21 +
 webview-ui/src/components/history/BatchDeleteTaskDialog.tsx |   7 +-
 webview-ui/src/components/history/CopyButton.tsx            |  16 +-
 webview-ui/src/components/history/DeleteTaskDialog.tsx      |   7 +-
 webview-ui/src/components/history/HistoryPreview.tsx        |   6 +-
 webview-ui/src/components/history/TaskItemFooter.tsx        |   2 +-
 webview-ui/src/context/ExtensionStateContext.tsx            |   1 -
 26 files changed, 2238 insertions(+), 247 deletions(-)

Context

The current task history persistence mechanism stores all history items directly in VSCode's globalState, which is causing several critical issues:

VSCode Warnings: The extension triggers VSCode warnings about excessive globalState usage:

WARN [mainThreadStorage] large extension state detected 
(extensionId: RooVeterinaryInc.roo-cline, global: true): 6173.2822265625kb. 
Consider to use 'storageUri' or 'globalStorageUri' to store this data on disk instead.

Extension Crashes and UI Issues: Users experience various issues that may be related to memory management and globalState limitations:
- Complete extension crashes or grey/white screens
- Memory leaks consuming all available RAM
- Possible globalState race conditions between VS Code instances leading to hangs, crashes, and VS Code instability
Performance Degradation: Even before crashing, the extension suffers from performance issues due to loading and processing large amounts of history data at once.
Scale Problem: A busy developer can accumulate tens of thousands of tasks over the course of a year. At this scale, the globalState approach becomes completely unsustainable.

Implementation

This PR implements a new architecture for task history persistence:

File-based Storage System:
- Store individual history items as JSON files in a task-based structure ('tasks//history_item.json')
- Use monthly index files ('taskHistory/.index.json') for efficient lookups and filtering
- Monthly index files use a workspace-to-task mapping format: {'workspace/path': {'task-id': timestamp}}
- Per-workspace index taskHistory/workspaces.index.json for fast workspace filtering (screenshot below)
- Implement in-memory caching and safe JSON utilities for data integrity
Performance Optimizations:
- Direct task retrieval without loading the entire history
- Monthly indexes for efficient date-based and workspace filtering
- Pre-filtering by date range at the index level before loading actual history items from disk
- Significant reduction in memory usage and improved search performance
Migration Process:
- Automatically migrate existing taskHistory data from globalState to the new file-based system
- Create a backup of the old data before migration
- Track version information to prevent repeated migrations
Integrity:
- Includes "History Index Tools" to scan/repair and reindex task history from the settings page

How to Test

Install the extension and verify that existing history is migrated correctly
Create new tasks and verify they are saved properly
View history and verify it loads correctly
Check that large history sets no longer cause VSCode warnings or crashes

Screenshots

Per-workspace filtering

This uses existing metadata, so it will immediately provide access to workspaces you have already used:

Performance Demo

2025-07-11.11-43-41.mp4

Get in Touch

Discord: KJ7LNW

Fixes: #3784

Important

Refactor task history persistence to use file-based storage, improving performance and scalability, with new UI components for management.

Behavior:
- Refactor task history persistence to use file-based storage in taskHistory.ts.
- Implement migration from globalState to file-based system with backup.
- Add monthly index files and per-workspace index for efficient lookups.
- Support direct task retrieval and pre-filtering by date range.
UI Components:
- Add HistoryIndexTools for managing task history in SettingsView.tsx.
- Update HistoryView.tsx to support new filtering and sorting options.
- Add SpinnerOverlay for loading states in SpinnerOverlay.tsx.
Misc:
- Remove taskHistory from globalSettingsSchema in global-settings.ts.
- Update ContextProxy to remove task history handling.
- Add tests for new functionality in safeWriteJson.spec.ts and safeReadJson.spec.ts.

^{This description was created by}^{for 8c9afbdb547f277a331d2fd6260b2f9b4d86548f. You can customize this summary. It will automatically update as commits are pushed.}

KJ7LNW · 2025-05-21T10:21:55Z

@cte @mrubens @hannesrudolph

This is a first pass to fix the growing bloat from task history that is stored in the global extension state. It assumes that #3772 has been merged for JSON safety.

The biggest point for review is that it converts existing global state task history into on-disk JSON structures. It converts my global state of 2800+ historical tasks quiet nicely, and I have verified the file output and all existing tasks and search functionality appears to function. Creating new tasks or modifying existing ones adds to the new JSON files and everything seems to proceed as expected.

There are still some optimizations to do:

history preview does not need to load all task history, as only 3 items are shown on the front page, so that will substantially speed up extension load time
the entire task list could theoretically load tasks in chunks by month, and then automatically load more as you scroll down, but I am not sure if I want to add that in an initial commit because it is complicated for things like searching that expect everything to be loaded. For now, it just loads all tasks into the task history interface (which is the same behavior as before)
there would probably be a first load spinner indicating conversion progress. My system it converts so fast I do not notice the difference but people who may have tens of thousands of boomerang tasks might notice.

This is an intentional break from backwards compatibility specifically for task history storage, however the old global state is not deleted, so if you downgrade to an older version (or if you are a developer testing things prior to this PR), you will still have everything that you used to have.

KJ7LNW · 2025-05-27T23:49:25Z

~~This PR is blocked by #4019 so please merge that first~~

* Improve documentation for new coders - Reorganized steps for better flow and clarity - Added missing hyperlinks for better navigation - Underlined hyperlinks for improved accessibility and visual consistency * Update docs/getting-started/for-new-coders.mdx Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com> --------- Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>

KJ7LNW · 2025-06-17T23:34:53Z

This single changes a 10x performance increase for every web view update because I have 2800 tasks in my history. The old form was O(n) of a new one is approximately O(log(n)):

                        currentTaskItem: this.getCurrentCline()?.taskId
-                               ? (taskHistory || []).find((item: HistoryItem) => item.id === this.getCurrentCline()?.taskId)
+                               ? await getHistoryItem(this.getCurrentCline()!.taskId)
                                : undefined,

KJ7LNW · 2025-06-17T23:44:06Z

here is another 2800x increase in performance which takes place every time a task is updated: notice that it used to always load the entire global state for every update, but that operation is now O(1) instead of O(n) because nothing ever used the return value, and all we need to do is save the history item:

-       async updateTaskHistory(item: HistoryItem): Promise<HistoryItem[]> {
-               const history = (this.getGlobalState("taskHistory") as HistoryItem[] | undefined) || []
-               const existingItemIndex = history.findIndex((h) => h.id === item.id)
-
-               if (existingItemIndex !== -1) {
-                       history[existingItemIndex] = item
-               } else {
-                       history.push(item)
-               }
-
-               await this.updateGlobalState("taskHistory", history)
-               return history
+       async updateTaskHistory(item: HistoryItem): Promise<void> {
+               await setHistoryItems([item])
        }

KJ7LNW · 2025-06-23T02:04:36Z

@daniel-lxs - this is ready for review ~~(but it in draft mode because it depends on #4733)~~

Review notes:

Currently rebased on github/use-safe-write-json-for-all-files, so the diff presently contains stray JSON commits. Ignore commits before Jun 22, 2025 (ie, this PR starts at safe-json-* for transactional JSON support)
Migration is not backwards compatible: this is by design so we can stop using the multi-megabyte global state taskHistory array which is slow and causes crashes

Migration is non-destructive: it creates new on-disk structures that replace the global state taskHistory array with well indexed structures in global storage:

 ]$ ls -l ~/.config/Code/User/globalStorage/rooveterinaryinc.roo-cline/taskHistory/
 total 184
 -rw-------. 1 ewheeler ewheeler    73 Jun 22 17:28 2025-01.index.json
 -rw-------. 1 ewheeler ewheeler 45581 Jun 22 17:28 2025-03.index.json
 -rw-------. 1 ewheeler ewheeler 62946 Jun 22 17:28 2025-04.index.json
 -rw-------. 1 ewheeler ewheeler 47495 Jun 22 17:28 2025-05.index.json
 -rw-------. 1 ewheeler ewheeler 16358 Jun 22 17:30 2025-06.index.json
 -rw-------. 1 ewheeler ewheeler  2076 Jun 22 17:30 workspaces.index.json

Anyone using this pull request will only see task history from the files above, so that means if you test it today, and it gets merged in 1-week, then you will appear to miss 1-week of tasks: To fix at all you have to do is delete taskHistory/ from the directory above and it will regenerate the indexes based on your current tasks. This only affects the following scenarios:
- Roo developers who test this PR and come back to it later
- Anyone who downgrades to an older Roo version
- Users would appear to "loose" tasks if this PR is merged and then reverted.
These issues are by design and expected.

Benefits

Much lower memory usage: all the heavy lifting happens in the extension, not the web view, and even the extension only loads the index is it needs to provide the search response
Faster task history updates: previously every task history update iterate in the entire task history O(n) but now a single HistoryItem update is on the order of O( log(n) )
- This Roo is much more responsive after a model response and when entering/exiting tasks in the UI
See earlier comments above for other performance fixes that were found as part of this refactor specific to this issue of HistoryItems
Per-workspace task history filtering: screenshot below
Default task history results to 50 items, sorted by date descending for fast load times and low memory pressure (users can still select all results if they wish)
Transactional JSON read-modify-write support

See the screenshots at the top post

KJ7LNW · 2025-06-23T02:26:29Z

Ready-to-test, here is the build:

https://www.linuxglobal.com/out/roo/roo-cline-3.21.2-refactor-use-files-for-history.vsix

Notice to testers:

Migration is non-destructive: it creates new on-disk structures that replace the global state taskHistory array with well indexed structures in global storage (see above for detail)
Migration is not backwards compatible: any new tasks used under this PR will not be visible in older Roo versions; existing old tasks are still visible in old Roo versions, so it is only new tasks that are affected.
It you delete ~/.config/Code/User/globalStorage/rooveterinaryinc.roo-cline/taskHistory/ and restart the extension, this PR will re-import from global-state taskHistory: you will loose access to anything you deleted during testing but the tasks themselves are not deleted, they are still in tasks/<uuid>

daniel-lxs · 2025-06-23T12:31:39Z

Thank you @KJ7LNW
I'll move this one back to draft in the meantime while we get #4733 reviewed and merged.

I'll review it as soon as that one gets merged.

This commit implements a new architecture for task history persistence: - Create file-based storage system for HistoryItem objects in tasks/<id>/history_item.json - Add migration logic to transition from old globalState array to file-based storage - Implement indexing by month for efficient searching - Cache history items in memory for performance - Provide backup of old data during migration Signed-off-by: Eric Wheeler <[email protected]> refactor: migrate task history to separate directory structure - Separated task items into 'tasks' directory - Moved monthly indexes into 'taskHistory' directory - Added helper functions for path generation - Improved backup file handling with explicit directory creation - Removed unnecessary cleanup logic - Enhanced error handling and logging Signed-off-by: Eric Wheeler <[email protected]> perf: optimize task history with concurrent operations and atomic file access - Add BATCH_SIZE constant to limit concurrent operations - Replace batch array with Set-based tracking for in-flight operations - Update getHistoryItem to use safeReadJson for consistency - Implement atomic read-modify-write for month indexes - Process month index updates in parallel - Add performance timing and metrics for migration - Check for directory existence before migration - Remove unnecessary directory creation Signed-off-by: Eric Wheeler <[email protected]> perf: optimize getHistoryItemsForSearch - Serialize calls to getHistoryItemsForSearch to allow cache to heat up - Skip taskHistorySearch when search query is empty - Extract implementation to private _getHistoryItemsForSearch function Signed-off-by: Eric Wheeler <[email protected]> refactor: use globalFileNames for history_item.json

…ions - Added HistorySearchOptions interface to packages/types - Updated WebviewMessage to use historySearchOptions field instead of individual fields - Added historyItems message type to ExtensionMessage - Implemented getHistoryItems handler in webviewMessageHandler - Refactored getHistoryItemsForSearch to accept HistorySearchOptions parameter - Completely replaced client-side filtering with server-side filtering - Removed dependency on Fzf for client-side search - Added loading state to history components with loading spinner - Updated HistoryPreview to use limit parameter and respect loading state - Updated tests to account for the new loading state - Set explicit limits for history items in ChatView (10) and HistoryPreview (3) This refactoring improves performance by moving filtering to the server side, enhances type safety with the dedicated HistorySearchOptions type, reduces duplication in the interface definitions, and improves the user experience with loading indicators. Signed-off-by: Eric Wheeler <[email protected]> refactor: improve history search sorting and filtering - Created dedicated HistorySortOption type in shared types package - Modified API to take year and month as direct parameters - Added helper functions to reduce code duplication: - _getTasksByWorkspace to extract tasks from month data - _fastSortFilterTasks for efficient pre-filtering and sorting - Ensured consistent sorting across all functions - Optimized filtering to happen before file reads - Added support for custom sort order in getAvailableHistoryMonths Signed-off-by: Eric Wheeler <[email protected]>

- Move fuzzy search from frontend to backend using fzf library - Create dedicated taskHistorySearch module with configurable parameters - Add match position tracking for proper highlighting in UI - Implement debounced search in frontend to prevent flickering Signed-off-by: Eric Wheeler <[email protected]> fix: maintain sort order during search When a search string is present, the sort order specified by the user wasn't being respected. This change ensures that: - Non-relevance sorts (newest, oldest, etc.) maintain their order when searching - The 'mostRelevant' sort option continues to use fuzzy search order Signed-off-by: Eric Wheeler <[email protected]>

Implemented automatic refresh of the task history list when tasks are deleted: - Added taskDeletedConfirmation message type to WebviewMessage and ExtensionMessage - Modified webviewMessageHandler to send confirmation after task deletion - Updated useTaskSearch hook to listen for deletion confirmation and refresh the list - Implemented non-flickering refresh that maintains current search parameters Signed-off-by: Eric Wheeler <[email protected]>

- Created SpinnerOverlay component to darken the view during deletion - Added state to track deletion in progress in HistoryView - Updated DeleteTaskDialog and BatchDeleteTaskDialog to trigger the overlay - Added event listener to hide the overlay when deletion completes Signed-off-by: Eric Wheeler <[email protected]>

Add request ID tracking to useTaskSearch hook to ensure each component only processes responses to its own search requests. This prevents the issue where multiple components using the hook would all receive updates when a search response comes back, regardless of which component initiated the search. - Add global serial counter to generate unique request IDs - Add component-isolated ref to track current request ID - Modify message handler to only process matching responses - Pass request ID back in webviewMessageHandler response Signed-off-by: Eric Wheeler <[email protected]>

Removed taskHistory field and all its references from the codebase as part of migrating to file-based storage. - Removed taskHistory from GlobalSettings schema - Removed import of historyItemSchema - Removed taskHistory from ExtensionState interface - Cleared PASS_THROUGH_STATE_KEYS array in ContextProxy - Updated ClineProvider to use file-based API instead of global state - Updated UI components to work without taskHistory prop Signed-off-by: Eric Wheeler <[email protected]>

Removed redundant useTaskSearch call from ChatView since HistoryPreview already makes its own call to fetch the tasks it needs to display. This eliminates an unnecessary API call on application startup and simplifies the component by removing conditional rendering based on task count. Signed-off-by: Eric Wheeler <[email protected]>

Remove unnecessary loading and returning of entire task history array. The return value was never used by any caller, so we can make this an O(1) operation instead of O(n) by simply saving the single item. This change significantly improves performance when updating task history, which happens frequently during task execution. Signed-off-by: Eric Wheeler <[email protected]>

Allows you to filter tasks not just by all and current, but also by any historic workspace directory that exists in existing HistoryItem metadata - Added persistent workspace index with metadata (path, name, missing status, timestamp) - Created a rich workspace selector UI with filtering and grouping capabilities - Added visual indicators for missing workspaces (strikethrough) - Improved loading states and feedback during workspace changes and searches - Added special workspace paths handling ("all", "current", "unknown") - Standardized empty/undefined workspace paths to "unknown" for legacy items that do not have workspace stored in their metadata - Optimized batch processing for better performance This enhancement provides users with a more intuitive and powerful way to navigate their task history across multiple workspaces. Signed-off-by: Eric Wheeler <[email protected]>

Added a limit filter dropdown to the history view that allows users to control how many results are displayed. The filter: - Defaults to 50 items - Offers options for 50, 100, 200, 500, 1000 items or all results - Shows loading spinner when changing limits - Integrates with existing workspace and sort filters - Maintains consistent search options across operations Signed-off-by: Eric Wheeler <[email protected]>

This change modifies the copy button in task history to retrieve the task content from the backend storage using getHistoryItem before copying it to the clipboard. This ensures the most up-to-date content is copied. Fixes: #3648 Signed-off-by: Eric Wheeler <[email protected]>

Implement a structured upgrade system that manages the task history migration process: - Create a dedicated upgrade UI that blocks normal app usage until migration completes - Separate migration check from migration execution for better control flow - Add progress logging during migration to provide user feedback - Remove automatic migration during extension activation - Add new message types for upgrade status and completion This change improves the user experience during task history migration by providing visual feedback and ensuring the app is in a consistent state before allowing normal usage. The upgrade system is designed to be extensible for future structural upgrades beyond task history migration. Signed-off-by: Eric Wheeler <[email protected]>

- Add tests for cross-workspace functionality - Verify items can be found in all workspaces where they existed - Ensure workspace property reflects the latest workspace - Add tests for helper functions and edge cases Signed-off-by: Eric Wheeler <[email protected]>

- Removed pass-through state tests from ContextProxy that no longer apply - Updated ClineProvider tests to use file-based history instead of global state - Modified ChatTextArea tests to use useTaskSearch hook instead of taskHistory prop - Completely rewrote useTaskSearch tests to use message-based architecture - Updated other tests to remove taskHistory references from mock states Signed-off-by: Eric Wheeler <[email protected]> test: Fix ClineProvider test by mocking extension context and taskHistory This commit fixes the failing test 'correctly identifies subtask scenario for issue #4602' by: 1. Adding necessary Vitest imports 2. Mocking getExtensionContext to return a mock context with globalStorageUri 3. Mocking taskHistory module to prevent file system operations during tests Signed-off-by: Eric Wheeler <[email protected]>

This change adds missing translations for the frontend UI. The missing translations were identified by the find-missing-translations.js script. The new translations are for the 'upgrade' and 'history' sections of the UI. Signed-off-by: Eric Wheeler <[email protected]>

KJ7LNW · 2025-07-18T21:01:31Z

rebased on v3.23.14

daniel-lxs · 2025-08-18T17:27:08Z

Thanks for the contribution. At this stage, the impact of these changes isn’t clear and we’re focusing on higher-priority items. Closing for now, but we can reconsider in the future if priorities shift.

github-project-automation bot added this to Roo Code Roadmap and Roo Code Roadmap May 21, 2025

github-project-automation bot moved this to New in Roo Code Roadmap May 21, 2025

KJ7LNW force-pushed the refactor-use-files-for-history branch from 3692f2d to b916aa4 Compare May 22, 2025 04:21

elianiva mentioned this pull request May 22, 2025

refactor: use external file for storing task history #3481

Closed

23 tasks

hannesrudolph moved this from New to PR [Draft/WIP] in Roo Code Roadmap May 22, 2025

hannesrudolph moved this from PR [Draft / In Progress] to TEMP in Roo Code Roadmap May 26, 2025

daniel-lxs moved this from TEMP to PR [Draft / In Progress] in Roo Code Roadmap May 26, 2025

daniel-lxs added the PR - Draft / In Progress label May 26, 2025

daniel-lxs assigned KJ7LNW May 26, 2025

This was referenced May 27, 2025

refactor: unify HistoryView and HistoryPreview with TaskItem to consistently use the existing HistoryItem interface #4019

Closed

Add global state storage size logging with threshold filter #3810

Closed

KJ7LNW mentioned this pull request Jun 2, 2025

Extension goes "blank" / Grey Screen #2270

Closed

KJ7LNW force-pushed the refactor-use-files-for-history branch 3 times, most recently from 39cc58b to fd6a2bb Compare June 23, 2025 01:23

KJ7LNW moved this from PR [Draft / In Progress] to PR [Needs Prelim Review] in Roo Code Roadmap Jun 23, 2025

KJ7LNW removed the PR - Draft / In Progress label Jun 23, 2025

hannesrudolph added the PR - Needs Preliminary Review label Jun 23, 2025

daniel-lxs moved this from PR [Needs Prelim Review] to PR [Draft / In Progress] in Roo Code Roadmap Jun 23, 2025

hannesrudolph removed the PR - Needs Preliminary Review label Jun 23, 2025

Eric Wheeler added 16 commits July 18, 2025 13:47

KJ7LNW force-pushed the refactor-use-files-for-history branch from 7a97986 to 4a8c77f Compare July 18, 2025 20:48

KJ7LNW moved this from PR [Draft / In Progress] to PR [Needs Prelim Review] in Roo Code Roadmap Jul 18, 2025

KJ7LNW removed the PR - Draft / In Progress label Jul 18, 2025

hannesrudolph added the PR - Needs Preliminary Review label Jul 18, 2025

daniel-lxs moved this from PR [Needs Prelim Review] to PR [Draft / In Progress] in Roo Code Roadmap Jul 21, 2025

hannesrudolph added PR - Draft / In Progress and removed PR - Needs Preliminary Review labels Jul 21, 2025

KJ7LNW moved this from PR [Draft / In Progress] to PR [Needs Prelim Review] in Roo Code Roadmap Jul 22, 2025

KJ7LNW moved this from PR [Needs Prelim Review] to PR [Draft / In Progress] in Roo Code Roadmap Jul 22, 2025

daniel-lxs closed this Aug 18, 2025

github-project-automation bot moved this from New to Done in Roo Code Roadmap Aug 18, 2025

github-project-automation bot moved this from PR [Draft / In Progress] to Done in Roo Code Roadmap Aug 18, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

3 of 3: scalability fix: refactor task history persistence to use file-based storage #3785

3 of 3: scalability fix: refactor task history persistence to use file-based storage #3785

Uh oh!

KJ7LNW commented May 21, 2025 •

edited

Loading

Uh oh!

KJ7LNW commented May 21, 2025 •

edited

Loading

Uh oh!

KJ7LNW commented May 27, 2025 •

edited

Loading

Uh oh!

KJ7LNW commented Jun 17, 2025 •

edited

Loading

Uh oh!

KJ7LNW commented Jun 17, 2025

Uh oh!

KJ7LNW commented Jun 23, 2025 •

edited

Loading

Uh oh!

KJ7LNW commented Jun 23, 2025 •

edited

Loading

Uh oh!

daniel-lxs commented Jun 23, 2025

Uh oh!

KJ7LNW commented Jul 18, 2025

Uh oh!

daniel-lxs commented Aug 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

3 of 3: scalability fix: refactor task history persistence to use file-based storage #3785

3 of 3: scalability fix: refactor task history persistence to use file-based storage #3785

Uh oh!

Conversation

KJ7LNW commented May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Note to Reviewer

Dependencies

Change Overview

Previously:

Upgrades!

Diff Annotation

Context

Implementation

How to Test

Screenshots

Per-workspace filtering

Performance Demo

Get in Touch

Uh oh!

KJ7LNW commented May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KJ7LNW commented May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KJ7LNW commented Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KJ7LNW commented Jun 17, 2025

Uh oh!

KJ7LNW commented Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review notes:

Benefits

Uh oh!

KJ7LNW commented Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Ready-to-test, here is the build:

Notice to testers:

Uh oh!

daniel-lxs commented Jun 23, 2025

Uh oh!

KJ7LNW commented Jul 18, 2025

Uh oh!

daniel-lxs commented Aug 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

KJ7LNW commented May 21, 2025 •

edited

Loading

KJ7LNW commented May 21, 2025 •

edited

Loading

KJ7LNW commented May 27, 2025 •

edited

Loading

KJ7LNW commented Jun 17, 2025 •

edited

Loading

KJ7LNW commented Jun 23, 2025 •

edited

Loading

KJ7LNW commented Jun 23, 2025 •

edited

Loading